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Abstract 

We solve the Expression Compatibility Problem (ECP) - a variation of the famous Ex- 
pression Problem (EP) which, in addition to the classical EP concerns, takes into consid- 
eration the replacement, refinement, and borrowing of algebraic datatype (ADT) cases. 
ECP describes ADT cases as components and promotes ideas from Lightweight Family 
Polymorphism, Class Sharing, and Expression Families Problem. Our solution is based 
on a formal model for Component-Based Software Engineering that pertains to the Ex- 
pression Problem. We provide the syntax, static semantics, and dynamic semantics of 
our model. We also show that our model can be used to solve the Expression Families 
Problem as well. Moreover, we show how to embed the model in Scala. 

Keywords: Expression Compatibility Problem, Expression Problem, Lightweight 
Family Polymorphism, Formal Semantics, Component-Based Software Engineering 


1. Introduction 

Expression Problem (EP) [1, 2, 3] is amongst the most famous problems in the com- 
munity of Programming Languages (PLs). A wide range of EP solutions have thus far 
been proposed. Consider [4, 5, 6, 7, 8], to name a few. The essence of EP is the challenge 
of finding an implementation for an algebraic datatype (ADT) - dehned by its cases and 
the functions on it - that: 

El. is bidirectionally extensible, i.e., both new cases and functions can be added. 

E2. provides strong static type safety, i.e., applying a function / on a statically con- 
structed ADT term t should fail to compile when / does not cover all the cases in 
t. 

E3. upon extension, forces no manipulation or duplication to the existing code. 

E4. accommodates separate compilation, i.e., compiling the extension imposes no re- 
quirement for repeating compilation or type checking of existing code. Such static 
checks should not be deferred to the link or run time either. 
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The main reason why EP is peculiarly recurrent in the PLs community is perhaps for 
it is customary to implement the syntax of a PL as an ADT. Then, the PL semantics 
as well as the analyses and transformations that pertain to the PL can all comfortably 
be considered functions on that ADT. As such, EP is prudent about minimising the side 
effects of extending an ADT with new cases and functions on it. 

On the other hand, family polymorphism [9] and its lightweight variations [10, 11, 12] 
focus on the software interdependencies in broader terms than PLs and the representing 
ADTs. They model a group of interdependent software artefacts together as a family, 
with the artefacts themselves being members of the family. The aim here is to keep the 
interdependencies upon the move to the next software release. Rather than addition of 
new members, the focus of study in family polymorphism is mostly on the next release 
refining (the functionalities of) the existing members to acquire a new family. 

It happens that, in addition to being extended by new pieces of syntax and semantics, 
a PL is also likely to refine some of its constructs over the course of time. It is, of course, 
of interest in such a situation too for the PL to retain its integrity. Nonetheless, except 
via nested intersection [13, 14, 15], the connection between EP and family polymorphism 
has hardly been a source of attraction. 

It also turns out that PLs sometimes replace older pieces of their syntax and seman- 
tics with newer ones. The impacts of such a replacement on the PL soundness constitute 
a classical source of interest for the PL community [16, §11]. Despite its importance, we 
are not aware of relevant studies in the held of EP. The following scenario deserves even 
more attention: PLs are commonly designed by borrowing constructs from a number 
of other PLs [17]. This is whilst the borrowed constructs are expectably designed only 
for integration within their original PLs. Institution Theory [18] has historically proved 
itself as a powerful tool for studying whether the packing of all those constructs together 
gives rise to a sound combination [19]. Again, the interplay of such a borrowing with EP 
is, however, an open question. 

In this paper, we introduce and solve the Expression Compatibility Problem (ECP), 
which is a variation of EP that also takes the following into consideration: rehnement, 
replacement, and borrowing of PL constructs. Components are a cornerstone to ECP. 
This is because, in order to ensure soundness properties such as the ones explained above, 
one needs to enforce constraints at the level of PL constructs. The implication is mod- 
elling PL constructs using components in their Component-Based Software Engineering 
(CBSE) sense. ^ With its above demand for components that are designed for cross-PL 
reuse, ECP is also a variation of the Expression Families Problem (EFP) [22]. The next 
paragraph gives an outline of ECP in terms of the EP terminology. For the rest of this 
paper, we dismiss the PL implementation concerns and employ the EP terminology. 

ECP is the challenge of finding an implementation for an ADT that uses components 
to address EP and: 

ECl. is independently extensible [23, 5] (a.k.a. extensionally unifiable [24]), i.e., it should 
be possible to compose independently developed extensions. 

EC2. is backward compatible, i.e., upon extension, the existing code retains its consistency 
and remains available for use - specially, to the extension^. 


^Consult Sommerville [20, §17] and Pressman [21, §10] for comprehensive discussions, 
^namely, guarantees both non-destructive and object-level extensibility [13, 8] 
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ECS. is scalable [13], i.e., adding a new case or function takes proportional code. 

EC4. ensures completeness of component composition, i.e., no valid combination of com- 
ponents should be rejected statically or dynamically. 

ECS. statically ensures soundness of component composition, i.e., provides means to en- 
force compilation failure for invalid component combinations. 

EC6. is combination sensitive, i.e., distinguishes between ADT types by their component 
combinations. In particular, the type identity of a core ADT should be distinguish- 
able from that of its extension. 

EC7. accumulates nominal subtyping, i.e., recognises the component combination ci as a 
structural subtype of C 2 when every case in ci is a nominal subtype of a case in C 2 . 

ECS. guarantees syntactic compatibility upon extension, i.e., statically rejects addition 
of new cases when the syntactic category of one existing case (or more) is neither 
retained intact nor refined. 

We call the first six the case concerns of ECP: those which are concerned with issues 
about ADT cases. Likewise, we call the first five plus the last two the function concerns: 
those concerned about functions defined on ADTs. That is, the first five are both case 
concerns and function concerns. One may wonder why ECS in presence of EC5? Firstly, 
ECS is particularly concerned about the sanity of extensions; whereas ECS is also about 
core combinations ab initio. Secondly, ECS is both a case and a function concern whilst 
ECS is only a latter. 

EC1-EC3 and ECS underpin new extension concerns w.r.t. EP. Refinement and 
removal concerns are EC4, ECS, EC6, and EC7. Then, replacement is the focus of EC4, 
ECS, and EC6. 

The list of our major contributions is as follows: 

1. We define ECP and present a solution for it in Section 2. 

2. In Section 4, we introduce as a formal solution to ECP. In summary, y^Co: 

facilitates minimal shape exposure using its family parameterisation; accommo- 
dates component late-binding using a notion component equivalence; and, features 
static dependency on the ‘requires’ interface of its components. 

3. We show how y'hC'o can be used to solve EFP as well. This is done in Section 5 by 
offering solutions to the two EFP exercises [22].^ 

4. In Section 6, we demonstrate highlights of how to simulate y^hCo in Scala. 

Here is how this paper is organised: We begin by Section 2 where the benefits of an 
ECP solution are highlighted. To put our work in context, we then explore the related 
work in Section 3. (The reader how is not familiar with that literature and is rather 
interested in the contents of the current paper might choose to skip over Section 3.) 
Afterwards, in Section 4, a formal presentation of 7 d>Co is provided. More particularly, 
the 7 $Co syntax comes in Section 4.1. Selected parts of the y^Co semantics that are 
in its front line of solving ECP are discussed in Section 4.2. How solving EFP can be 
accomplished in 7 $Co is, then, shown in Section 5. Next, Section 6 explains how to 
simulate the y4>Co material of this paper in Scala. Conclusion and future work come 


•^Those exercises are designed for exhibiting the power of Modular Visitor Components (MVCs) for 
solving EFP. 
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in Section 7. Finally, Appendix A and Appendix B detail the static and dynamic 
semantics of 7 $Co, respectively. 

In this paper, we only show how to employ 7 $Co for compositional analyses and 
transformations [25]. For how to employ 7 $Co in non-compositional scenarios, see [26, 
§8]. In addition, we will follow the EP tradition of using basic integer arithmetic as 
the running example of this paper. To examine the performance of our material under 
real research languages, the reader is invited to consider [26]. The material that we 
present in this paper, including both the 7 d>Co and the Scala code, is available online at: 
http : //www. sts .tu-harburg.de/people/hossein/ecp.html. 


2. Once upon a time when ECP was already tackled. . . 

This section aims to explore the potential opportunities that a solution to ECP will 
create for safe reuse. That is accomplished by a rapid presentation of how manages 

to address ECP. On our way, we will introduce the relevant 7 $Co features and the 
techniques needed to get them to serve our purpose. 


Components. We begin the show with the introduction of a few ADT cases. 7 $C'o 
facilitates that using its special support for component definitions: 


01 component Num<X <\ Num> { 

02 int n ; 

03 Num{\nt n) {this.n = n;} 

04 } 

09 component Add<X <\ Add> { 

10 X left, right; 

11 Add{X left, X right) { 

12 th\s. left = left; th\s. right = right; 

13 } 

14 } 


05 component UNm<X <l UNm> { 

06 uint n; 

07 {7Am(uint n) {this.n = n;} 

08 } 

15 component Sub<X <\ Num(B Sub> { 

16 X left, right; 

17 Sub{X left, X right) { 

18 th\s. left = left; th\s. right = right; 

19 } 

20 } 


The code above introduces four components for ADT cases for signed integers, un- 
signed integers, addition, and subtraction. Those are Num (lines 01-04), UNm (lines 
05-08), Add (lines 09-14), and Sub (lines 15-20), respectively. The body of a component 
is like that of a class in Igarashi et al. [27]: Line 02 above states that Num has a field 
n of type int. Line 03 demonstrates Num’s constructor. And, although not shown here, 
'Y^Cq components can also define (non-constructor) methods. 

Unlike an Igarashi et al. class, however, a component enjoys family parame- 

terisation too. This is for a component to express its ‘requires’ interface ([20, §17] and 
[21, §10]). Eor example, line 15 above states that Sub ‘requires’ for its container ADT 
to contain Num and Sub. (In this paper. Sub represents signed subtraction, exclusively. 
Hence, it ‘requires’ the signed integer case - i.e., Num - as well.) Inside SuVs body, the 
family parameter X plays the container role and is to be substituted for a family. (See 
below for more.) Built-in types aside, the only types allowed inside a component body 
are its family parameter (e.g., lines 10 and 11 above) and the components it ‘requires’. 
(For types of the latter group, see lines 02 and 05 in EN and EU discussed later on.) 
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01 

03 

04 
06 


family $o = UNm(BAdd; 02 family = Num (B Add ■, 

family $2 = UNm(B Sub; //Error! Sub requires Num too. 
family ^3 = Num (B Sub; 05 family ^4 = Num (B Add (B Sub ; 

family $5 = Sub; //Error! Sub requires Num too. 


Families, EC4, and ECS. A 7 $Co family definition can be employed for an ADT intro- 
duction. As shown above, a family definition is as simple as listing the components it 
contains. Families $ 0 , $ 1 , $ 3 , and $4 are examples of q^hCo’s support for EC4: The 
programmer is entitled to mix components in all valid ways. On the contrary, $2 and 
4)5 attempts are statically rejected. Those are examples of q^hCo’s support for EC5. 


Clients. Functions on ADTs are implemented in q4>(7o using its so-called elient defini- 
tions. The two differences between q^hCo components and clients are as follows: Firstly, 
the former can have fields as well as methods, but, the latter is only a pack of methods. 
Secondly, the former takes a single family parameter, whilst, the latter can take multi- 
ple such parameters. Whilst the first difference is displayed in this section, the second 
will only be discussed in Section 4. The code below on evaluation of integer arithmetic 
expressions is an example of how to define functions on ADTs. 

01 client EN<X <l Num> {//signed integer evaluation 

02 \r\t eval{X. Num X, int e(AT)){return x.n; } 

03 } 

04 client EU<X <l UNm> {//unsigned integer evaluation 

05 u\nt eval(X.UNm X, int e(AT)){return x.n; } 

06 } 

The most noteworthy point about the two clients above is that they only handle their 
own part of evaluation. Note that, in order to handle a case, explicit nomination of the 
case is required. The consequence, which was also stated earlier on, is that: any attempt 
to handle other cases than the ones nominated in the ‘requires’ interface will be statically 
rejected. For example, would it happen that the programmer mistakenly chooses to 
handle subtraction in EN, a compile error will be emitted. The second parameter of eval 
(in lines 02 and 05 above) represents the complete evaluation recipe, the role of which 
will become more clear below. 

01 client ENA<X <l Num® Add> {//signed integer and addition evaluation 

02 int eval{X x, int e{X)){ 

03 return x match { 

04 case X.Add ^ e{x.left) + e{x. right) ; 

05 case X.Num => EN<X as Num>.eval{x, e) ; 

06 } 

07 } 

08 } 

Consider line 04 above, where the joy of compositional evaluation and component- 
based development are experienced in tandem: Not having the complete recipe, it leaves 
evaluation of subexpressions to the parameter e. At the same time, only the addition case 
is handled by that line. The action of line 05 is slightly different, where handling the case 
(of signed integers) is relayed to the eval method of EN. More remarkable is the use of 
family parameter projection for the relaying. When not all the components of ‘requires’ 
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interface are to be passed in the exact same order, 7 <i>Co demands explicit nomination of 
the relevant ones. Otherwise, the family parameter alone can be nominated. (See Eval^ 
and Eval^ below.) 

EC7 and ECS. Liire 05 above also demonstrates another important property of y'hC'o, 
i.e., how it addresses EC7: It is legal for ENA to reuse the EN methods for its ‘requires’ 
interface is a superset of that of EN. The dual of that is how the following piece of code 
fails statically due to 7 <I>( 7 o’s implementation of ECS. 

01 client BadENA<X <l Num® Add> { 

02 ... EU<T!l>.eval{. . . ); //Error! Invalid projection. 

03 } 

The reader is invited to take their time to observe that no valid combination of the 
components in the ‘requires’ interface of BadENA can be substituted for 111 in line 02. 

ECl. Due to its similarity, we drop the definition of ENS<X <J Num® Suh> to move 
to the demonstration of how 7 d)Co addresses ECl as a function concern. The lines 04 
and 05 below show how ENAS composes independently developed extensions of EN, i.e., 
ENA and ENS. (It is trivial to observe that y'hC'o’s family definition facility addresses 
ECl as a case concern.) 

01 client ENAS<X <l Num® Add® Suh> { 

02 int eval{X x, int e{X)){ 

03 return x match { 

04 case X.Add => ENA<X as Num® Add>.eval{x, e); 

05 case X.Sub ENS<X as Num 0 Suh>.eval{x, e) ; 

06 case X.Num => EN<X as Num>.eval{x, e) ; 

07 } 

08 } 

09 } 

Tests. In order to bring the above clients to action for the defined families, one first ties 
the recursive knot. Evali and Eval^ below demonstrate that for 4>i and $ 4 , respectively: 

01 client Evali<X <\ Num ® Add>{ 06 client Evalj,<X <\ Num ® Add ® Suh>{ 

02 int doJt{X a:){ 07 int dojit{X x){ 

03 return ENA<X>.eval{x, dojit); 08 return ENAS<X>.eval{x, doJt); 

04 } 09 } 

05 } 10 } 

Then, one instantiates the clients using the families defined earlier. Here are some tests: 


6 


01 val tpf I = new Add<^i> {new Num<^i> (3), new Num<^i> {5)) ; 

02 val tpf ^ = new Add<^ 3 >{new Num<^ 3 >{ 3 ), new Num<^ 3 >{ 5 )) ; 

^ //Error! $3 doesn’t provide Add. 

03 Evali<^i>.doJt{tpfi); //Returns 8. 

04 val tp/4 = . . . //3 + 5 for $4 

05 val tpfmo^^ = new Sub<^ 4 >{tpf new Num<^ 4 >{l)) ■ 

06 Eval.^<^ 4 >.doJt{tpf 4 ); //Returns 8. 

07 Evali<^ 4 >.do-it{tpf 4 )-, //Error! case of $4 unmatched by EvaZi. 

08 Eval 4 <^ 4 >.doJt{tpfmo 4 ); //Returns 7. 

09 Evali<^ 4 >.doAt{tpfmo 4 )\ //Error! b’ufc case of $4 unmatched by if z;aZi. 

10 Evali <^4 as Add 0 Num>.doAt{tpf 4 )-, //Returns 8. 

11 Evali <^4 as Add 0 Num>.doAt{tpfmo 4 ); 

^ //Error! tpfmo 4 contains other $4 cases than Num and Add. 

Other ECP Concerns. We end by a short explanation on how addresses the re- 

maining ECP concerns. The support for EC2 is obvious for addition of new components 
and clients has no effect on existing programs. 7$Co does also clearly support 

ECS: Addition of a new case amounts to defining the respective single component; addi- 
tion of a new function on n cases (say for pretty-printing) amounts to defining (at most) 
n new clients for the corresponding cases and a single client to tie the recursive knot. 
Understanding that 7$Co addresses EC6 is also easy: Defining a new ADT (say as an 
extension to an existing one) is a matter of defining a new 7d>Co family. Such an addition 
influences no existing family (especially that of the core ADT, if any). A family is distin- 
guishable from other families (including its core, if any) by its name. On the contrary, 
clients are equally (un-)available to families with identical component combinations. 

Remark 1. Note that, although after tying the knot for Evali or Eval^, they are no 
longer extensible, that is not a failure in addressing EP. The reason is that the evaluation 
service that was available to $1 and $4 essentially come from ENA and ENAS, which 
remain extensible upon tying the knot. 

Remark 2. The clients presented in this section perform the evaluation task in a 
component-based fashion. The technique we used to that end is the additive [20, §17.3] 
flavour of what we call integration of a decentralised pattern matching [26, §9]: Instead 
of centralising the pattern matching in a single place, we distribute it amongst clients 
that correspond to the cases of the task. This section, nonetheless, was rather focused on 
the ECP concerns. We postpone dedicated explanation until Section 5 where a clearer 
account of the technique is developed. 

3. Related Work 

This section classifies the relevant literature according to their proximity to this paper. 
Each classification ends in a summary of how they are similar to or different from our 
work. Inside a classification, an outline of each work is accompanied by a short description 
of which ECP concerns they manage or fail to score. 
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Family Polymorphism 

Family Polymorphism [9] aims to ensure that certain interrelationships between the 
constituents of a system - referred altogether as a family - are all extension-invariant. 
Family Polymorphism is a meritorious tool when families with identically-named mem- 
bers that are of identical relative types are to be distinguished from one another. But, 
otherwise, sharing classes amongst distinct families (with even identically-named mem- 
bers of identical relative types) is notoriously challenging [28]. ECl and EC2 have clear 
support in Eamily Polymorphism. Given its difficulties in cross-family class sharing, 
whether Eamily Polymorphism can also support EC3 is hard to judge. In order to exam- 
ine whether the other ECP concerns can also be addressed, one needs to first decide on 
the counterpart Family Polymorphism offers for components. The immediate candidate 
is the pattern concept of gbeta [29] that generalises the familiar OOP class concept. One 
might manage to employ virtual constraints [30] to get the pattern concept to simulate a 
component. (The simulation will perhaps be accomplished like how Scala traits and type 
constraints are employed for the same purpose. See Section 6.) Given the acquired taste 
of programming in gbeta, however, we did not try that simulation. We, hence, cannot 
assess how addressable the remaining EGP concerns are by Family Polymorphism. 

Class Sharing 

Jx [31] starts a series of works on sharing nested classes amongst families. Jx itself only 
allows that amongst hierarchies of families. J& [13] generalises that to intersection types 
[32] to cater extension composition (cf. ECl). Of the ECP concerns, it also addresses 
EC3 (using late-binding) and EC2. In J&g [14], sharing of classes amongst families is 
nomination-based but not restricted to those which are hierarchically related. [15] 
moves to homogeneous class sharing, where a core family and all its extensions are 
equivalent. To that end, when a new family extends a core family, J&/j automatically 
updates all the equivalent families (including the core itself) with the extensions provided 
by the new family. Such an update is likely to risk EC2. 

The similarity between nested family classes and our components makes J&s partic- 
ularly close to our work. Yet, there are at least three significant differences between this 
entire thread of research and that of ours: First, the sharing of components between a 
base family and its extensions is not limited in our approach to identical components; 
substitution for equivalent ones is equally acceptable (cf. Remark 10). Second, in their 
research thread, the shared classes have tight dependencies to their enclosing families 
(hierarchically, heterogeneously, or homogeneously). That is, addition of a new class (for 
sharing) amounts to addition of a new family or updating an existing one. In either case, 
(re)compilation of an enclosing family is inevitable. Our components are, however, not 
dependent on any family. (In fact, they are even not enclosed by a family.) Addition of 
a new component implies compilation of nothing but the component itself. Third, with 
their independent nature, components can enforce constraints on the families they are 
chosen for inclusion in. Shared classes, on the other hand, have no control over that to 
the degree that they can be shared via arbitrary enclosing families (subject to certain 
workflow disciplines that are out of scope here). 

Lightweight Family Polymorphism 

Having observed the heavy workload of family polymorphism in certain circumstances, 
Saito, Igarashi, and Viroli [10] craft lightweight family polymorphism. Similar to family 

8 


polymorphism, they target extensibility of mutually recursive classes. Yet, inspired by 
Jolly et al. [33], they adopt a “classes-as-families” principle. Saito, Igarashi, and Viroli 
develop a formal model .FJ for lightweight family polymorphism, for the type system 
of which they also prove an important correctness theorem. In .FJ, families and their 
members are represented using top-level and nested classes, respectively. In 7 $Co, how- 
ever, both families and components are top-level. An “inheritance-without-subtyping” 
approach is taken in .FJ for family members. That is, whilst a same-named nested class 
of an extending family does (automatically) inherit from that of the base family, there is 
no subtyping relationship between the two nested member classes. We take a different 
approach: components that are common between two families are indeed the same 

(and, hence, in a subtyping relationship). Finally, .FJ addresses EC2 and EC3. It fails 
to address ECl because it only supports extension using single (nominal) inheritance of 
top-level families. Eor its lack of counterpart for components, the rest of ECP concerns 
are irrelevant to .FJ. 

Kamina and Tamai [11] notice the monolithic nature of (lightweight) family polymor- 
phism in that family members are inseparable from their enclosing families. They craft 
FGJ^ to get what they call type parameter members. Using this addition, they can take 
interfaces of family members out of family bodies so that members are no longer nested 
classes of families. Consequently, families and their members gain independence to the 
level of separate compilation from each other. However, addition of a new member is still 
not possible without first providing a new family interface that adds a new type parame- 
ter to correspond to the new member. It is only thereafter that one is authorised to refer 
to the new member using their type parameter member notation. Kamina and Tamai 
do not discuss whether reuse of the FGJ# code that works for a base family is valid for 
an extension that adds new members. Hence, whether FGJ# supports EC4, EC7, and 
ECS is not known. On the other hand, for similar reasons to .EJ, EGJ# addresses EC2 
and EC3 but not ECl. Its move towards components shapes an interesting behaviour 
w.r.t. the rest of ECP concerns. It can simulate them all so long as an ADT interface 
hard-wires the relevant requirements. 

Lightweight dependent classes [12] is the next work of Kamina and Tamai, with re- 
markable proximity to Aiming at reducing the boilerplate code of the above two 

works of the section, they take one further step toward getting component-based. They 
provide X.FGJ consisting of member interfaces and families. In X.EGJ, a family materi- 
alises its members by providing nested classes with empty bodies that derive from their 
respective member interfaces. Besides, by abstracting members to the level of member 
interfaces, defining extensions which refine existing ADT cases is rather straightforward. 
Despite all its improvements, in X.EGJ too, defining new members is only possible in 
tandem with defining new families which materialise the respective new member inter- 
faces. Interestingly enough, this is due to the fact that in X.EGJ, members are nested 
classes of their enclosing families. On the contrary, components are completely 

detached from the families they are to be members of. Our final remark about X.EGJ is 
that it scores similar to FGJ# regarding the ECP concerns. 

Whilst the works in this group are particularly sophisticated on case refinement, they 
are almost silent about addition of new cases. ECP, however, is concerned about both 
sorts of extension. That is also why provides direct means to address both. 
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Expression Families Problem 

Oliveira was the first to frame EFP. He also offered MVCs [22] as an EFP solution. 
Oliveira and Cook [6] back this work up by the powerful and simple concept of object 
algebras [34]. Later, Oliveira et al. [35] try to address awkwardness issues faced in their 
former paper upon composition of object algebras. As detailed by Haeri [26], which 
element in the latter two works to compare against 7 $Co components (and families) is 
not straightforward to us. With that difficulty in assessment, we only concentrate on 
Oliveira’s seminal work in what follows. 

MVCs address all EC concerns except EC3, EC5, and ECS. Their support for EC7 
is worth a special attention: In his machinery, Oliveira chooses an extension to be a 
supertype of a core. Whilst the reason for that choice is not clear to us, we wonder 
whether the consequence is that they support EC7 in the same direction of ours (ci 
subtype of C 2 ) or the opposite one. Like Zenger and Odersky [36] - and in line with the 
entire OOP literature - we choose an extension to be a sufetype of a core ADT. This is 
a special case of our EC7. 

Expression Problem 

Of the rich literature on EP we only consider a couple that we deem close enough to 
this paper. Garrigue [37] solves EP using global case definitions that, at their point of 
dehnition, become available to every ADT defined afterwards. Per se, a function that 
pattern matches on a group of these global cases can serve any ADT containing the 
selected group. Garrigue’s work is based on OCaml’s built-in support for Polymorphic 
Variants [38] and addresses all the ECP concerns except ECS and EC6. Yet, from ECP’s 
standpoint, the most important missing factor is a notion of components in this work. 
Rompf and Odersky [39] employ a fruitful combination of the Scala features to present a 
very simple yet effective solution to EP using LMS. The support of LMS for E2 can be 
easily broken using an incomplete pattern matching. Yet, given that pattern matching 
is dynamic, whether LMS really relaxes E2 is debatable. Although LMS is not based on 
components, it scores all the ECs except ECS, EC6, and ECS. 

4. 7$Cq: a Formal Solution to ECP 

As a PL, 74 >Co is highly inspired by the popular informal models of CBSE. Most 
remarkably, that includes the works of Pressman [21, §10] and Sommerville [20, §17]. 
7 $Co is, however, especially tuned for ECP. The opening discussion of this section will 
delve into the design choices made accordingly. From a PL designer’s perspective, on 
the other hand, one would be interested in finding out about the axes along which to 
tweak the PL for reuse. In the favour of that interest, over the opening discussion, 
we further elaborate on the two sources of polymorphism in 7 <I>Co. After the opening 
discussion. Section 4.1 presents the 7 $Co syntax. Next, in Section 4.2, we will focus on 
the most immediately relevant parts of the 74>Co semantics to the ECP concerns. For 
the complete semantics, see Appendix A and Appendix B. We now move to the 

opening discussion itself. 

The 7 $Co world has three major role-players: components, families, and clients. A 
component takes after its well-known CBSE identity by specifying its ‘requires’ 
and ‘provides’ interfaces. It specifies its ‘requires’ interface using family parameterisation. 
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The ‘provides’ interface of a 7 $Co component is specified just like a familiar OOP class. 
7 $Co families are simply defined as a collection of their respective components. Clients 
in 7 $Co are pieces of code that are applicable to any family, provided that the family 
contains the specified minimal component combination.'^ (See Figure A. 11.) This is 
the first source of polymorphism in 7 $Cq: A client (or component) code can be reused 
amongst all such families (but, not other ones). We refer to this property as the minimal 
shape exposure. Again, 7 d>Co uses family parameterisation to that end. Minimal shape 
exposure is particularly geared towards EC4, ECS, and EC6. 

Polymorphism in 7 d>Co comes from another source as well: component late-hinding. 
The family parameterisation used for a component or client enforces the availability 

of certain components. Instead of providing the exact requested components, however, 
the family is free to mix an equivalent component in. (See (S-WEP) and (S-PEP) in 
Figure A. 12.) As such, the exact behaviour of a family-parameterised code is not known 
until the actual family used for instantiation is provided. This is our notion of component 
late-binding. This source of polymorphism serves EC7 and ECS most specifically. 

In the presence of the above two sorts of polymorphism, 7$(7o components, clients, 
and their methods are all chosen to be type-monomorphic. Type polymorphism is already 
well researched, and, we see little extra service that type-polymorphic elements can bring 
to ECP, if any. Eor similar reasons, is designed with no inheritance between 

components or clients. Furthermore, with our lack of applications where a component 
ought to take multiple family parameters, 74>Co chooses components to take a single 
family parameter. 7$(7o clients, on the other hand, are eligible to take more than one 
family parameter.® 

By specifying its ‘requires’ interface using family parameterisation, a 7 $Co client 
(or component) determines the component combination it expects from the family that 
is going to use it. The client (or component) code, then, will be statically bound to 
the requested combination. (See (WF-VCase) in Figure A. 10 and (T-Test) in Fig- 
ure A. 14.) Inside the body of a client (or component), any attempt to access unrequested 
components is outlawed statically. We refer to this feature as static dependency on the 
‘requires’ interface. 

For the rest of this paper, we maintain the following conventions: Unless otherwise 
stated, when we refer to components, families, and clients, we mean the y'l’C'o ones. 
Moreover, is our wildcard; it shows our lack of interest in the exact piece of information 
that is used in place of. 

Remark 3. Unlike the code snippets of Sections 2 and 5, the formal model that is pre- 
sented in this section for 7 $Co does not include the following features: component-based 
pattern matching (e.g., lines 03-07 of ENAS), built-in types (e.g., line 02 of Num), 
functions-as-arguments (e.g., line 02 of EN), and top-level variables (e.g., tpf^ in Sec- 
tion 2.). Our impression is that, although programmatically valuable, the lack of those 
features is no loss for the formal model as a core calculus. 


^As such, a client is like a set of family-polymorphic methods in its .FJ [10] sense. The main difference 
is that .FJ enforces inheritance from a top-level family, whilst 7 ^Cq enforces the availability of certain 
components (and absence of the others). 

^All that simplification together might of course become deceptive about 7 $Cq. We would, therefore, 
like to invite the reader to investigate the power of in Sections 5 where long-standing research 

challenges are easily taken up. 
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Remark 4 (CBMCalc Comparison). 74>Co is, in fact, a successor of CBMCalc 
[ 26]. The main differences between the two are that 74>Co 

1. gives ECl a first-class support using its simple mechanism for cross-client method 
calls. CBMCalc can only simulate that using linearisation of multiple inheritance. 

2. ships with no inheritance for components or clients. CBMCalc ships with inheri- 
tance for both. 

3. is designed not to include super calls. This is a consequence of observing the 
absence of a mixin flavour in CBMCalc’s use of inheritance. 

4. allows clients to take more than one family parameter. 

5. also models Common Reuse Principle [40] for components, (cf. Remark 5.) 

4 - 1 . The 7$Co Syntax 

Figure 1 shows the syntax of 7$Co. Here, 7 ranges over components, C over clients, 
K over constructors, m over methods, x over method parameters, e over expressions, 
/ over fields, $ over families, and X over family parameters. We take this to be a 
reserved variable name. Priming a syntactic metavariable or subscripting it with numbers 
does not change its syntactic category. When distinction between a metavariable of a 
component and that of a client is required, we use subscripts 7 and C. When referring 
to both categories collectively, we drop the subscript. For example, and me denote 
component methods and client methods, respectively, but m can be either an or an 
me- Note that neither subscript is related to a particular component 7 or client C. 

The syntax in Figure 1 is divided into two parts: relative and absolute. The former 
syntax is all relative to the family parameters and is about before substitution of (real) 
families for the family parameters. The latter, on the other hand, is regarding after 
family introduction, wiz., when some defined families get employed for substitution for 
the family parameters of the relative syntax. 

Following the tradition of lightweight family polymorphism (Section 3), the overline 
notation is used for a list of entities and #(.) for the length of a list. For example, for some 
known n: 7 denotes 7172 . . . 7«, and, this./ = / denotes this./i = /i, . . . ,this./„ = /„. 
The notation 7 is also overloaded to mean the list 71, 72, . . . , 7n, when appropriate. We 
extend that notation for 07 to mean 71 © 72 0 • ■ • 7n • We overload the notation one 
further step to mean Xi <l 071,^2 <1 ©72, • ■ • ,Xn <1 ©7„ by X <l ©7. We use e for 
empty lists. 

Using the relative syntax, one can define components (7) and clients (C). Both 
clients and components take family parameters. The notation X <3 ©7 stipulates that 
the family to be substituted for X has to include components (that are equivalent to) 
7i , 72, . . . , 7n. In such a case, we say that ©7 is the upper bound of X. Similarly, we say 
that 7i is an upper bound of X, for i = 1, 2 , ... , n. We call n the upper bound size of X 
- written as #X = n - when X <l ©7 and # © 7 = n. When 7 is an upper bound of X, 
the relative type X.7 - read the component 7 of X - is the component substituted for 7 
when substituting a family for X. 

When a method of a client G calls a method of another client G', the caller needs to 
state the family parameter(s) of G to be used for substitution for the family parameter(s) 
of G' . In such a call, when the family parameter X of G is to be used for X' of G', two 
possibilities are available: G'< ■ ■ ■ , X, • • • > and G'< • • • , X as © 7, • • • >. In the first case, 
the same family eventually substituted for X in G will be substituted intact for X' in 
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Relatives 


Dc 

G 

R 

S 

K 

Me 

G-f 

ec 


Z 

A 

I 

T 

V 


= component 'y<X a 07 ^ 7> <l {Rf; 
= client C<X <1 07>{Mc} 

= 7 I c 
= X \ X.J 
= X \ X as 0 7 
= = / :} 

= R m^{R x){return ; } 

= R mc{R x){return ec',} 

= X I Cr-f I er.m^(^) I new X.^{^) 

= €r I TOc(ec) I C<S>.mc{ec) 


K M^} component definition 
client definition 
relative definition name 
relative type 

family parameter selection 
constructor 
component method 
client method 
relative expression 
client expression 


Absolutes 


= family d) = 07 
= d) I $ as 0 7 
= Z I 7<Z> 

= c<z> 

= D,s,;I.mc(v) 

= Ca-f I Ca-m^iGi) I new j<Z>{Gi) \ I.mciGi) 
= new j<Z>{v) 


family definition 
family selection 
absolute type 
client instance 
test 

absolute expression 
value 


Figure 1: The 7<FCo Syntax 


G' . The second case signifies the situation when only the selected components 7 of the 
family substituted for A in G will substituted for X' in G' . We say, in such a case, that 
X is projected to 07. Additionally, we call A as 0 7 a family parameter projection. The 
projection of a family parameter is a must when jfX' ffX.^ That manifests the role 
of S in Figure 1 . Z plays a similar role for the absolute syntax. 

The syntax for introduction of a family is as simple as enumerating the components it 
combines, interleaved by “0”. To test a client on a family, one calls a method of a client 
by passing appropriate arguments to the method. To that end, either the whole family is 
used for client instantiation (G< • • • ,<&,•••>) or a projection of it (G< • • • , $ as 07, •••>). 
Note that, unlike components, we choose clients to store no data and simply act as a 
collection of methods. As such, clients need no constructors. 

A test T contains a sequence of family introductions and a single call to a method of 
a client instantiated by the introduced families (or their projections). A 7 $Gq program 
is a test along with the components and clients that it uses. For a 7$Go program to 
compile and run, we assume the availability of two more ingredients: First, a customary 
class table CT, which is a simple mapping from the names of the program components, 
clients, and families to their bodies. We assume similar sanity conditions for CT to 


®This syntax is also meaningful when the order of components to be passed to G' is not exactly the 
same as their order of appearance in G’s definition. Yet, the discussion in this paragraph is not particu- 
larly concerned about the order in which components are enumerated. The order becomes significant in 
the subsequent sections when same-indexedness is assumed. See Figures A. 5, A. 9, and A. 11 as well. 
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those assumed by Saito et al. [10]. Second, an equivalence relation = as a repository 
for the components to be considered equivalent. (More on the = relation of in 

Remark 10.) 

When the premises of a y'hC'o rule contain a statement of the form 7 {- • • }, we are 
abbreviating CT{'j) — component y{ - • • }. The situation is similar for clients. Likewise, 
= 07 abbreviates CT(d)) = family $ = 0y. With such abbreviations, we drop the 
explicit mention of CT over 7 $Co rules. 

Remark 5. Note that, for a definition component y<X <l 0y yj •••>{•••}, it is valid 
that 7' G 7 whilst 7 yf 7'. That is, a 7 $Co component can enforce the availability of 
other components than itself. This is particularly useful for implementing The Common 
Closure Principle (CCP) of Martin [40]: “Classes that change together belong together.” 
Similarly, the “yj 7” part of the notation is designed to implement The Common 
Reuse Principle (CRP) of Martin [40]: “Classes that aren’t reused together should not 
be grouped together.” The conflict between CCP and CRP is, of course, semantically 
wrong in that classes cannot both change together and not be reused together. That is 
taken care of by (NC-Comp) in our semantics by refusing the presence of a component in 
both the “o 07” part and the “yj 7” part of a single (cf. Figure A. 9). More general 
family parameterisation that can describe arbitrary relationships between components 
can soon slip into computability difficulties that we would like to avoid. 

4-2. How does address ECP? 

This section gives an overview of the static semantics parts of y^Co that help it solve 
ECP. Given that ECS is only quantitative, this section will not take that concern into 
account. On its way, this section first explains the three most directly related rules of the 
7 $Co semantics. Then, it proceeds by discussing how each ECP concern is addressed by 
which of the three rules. 


P; C 'rje-jie fps{C) = X' #X' = #S 
C h ssfp{S, X', C) ok mtype{mc, C) = R' ^ R' 

R = 7 ^[C' C'] ChRlci? R = R'[C-t^^C"] 


P;Ch C'<5'>.mc(e) : R 


(T-INVK 3 ) 


7 = fpub*{^) sat-by{'f, 4)) 

family 4> = • • • ok 


non-confM 

(WF-Family) 


Dq, ok I ok mtype{mc,I) = A — )■ A 
Z = fsel{v) I = C<T> Z = ^ 
as-fam{Z) \- v ■. A' as-fam(Z) h A' <: A 

; I.mciv) : A 


(T-Test) 


Figure 2: The Rules of 7 <t>Co that Most-Directly Address ECP 


Figure 2 illustrates the three rules mentioned above. The clauses used in those rules 
are likely to look extraordinarily compact to the untrained eye. Before we get into the 
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intuition behind each rule, we would like to invite the reader to check Figure 3 for the 
abbreviations used in Figure 2. Likewise, Figure 4 expands on the names of the helper 
functions used in Figure 2. The exact definitions of the helper functions can be found in 
Appendix A. We now continue to the rules. 

With its number of premises the rule (T-INVK 3 ) might look daunting at the first sight. 
Below, we explain it informally in a top-down and left-to-right fashion. The rule states 
that, within the body of a client C, in order for a call to a method me of C to return a 
value of type R: The argument types Re need to be determined (F; C h e : i?e); the passed 
selections S to C’ need to have the right number {fps{C) = X' and #A' = #5'); the 
pass of all selections S from C to their same-indexed family parameter amongst X' of C 
needs to be valid (C h ssfp{S, X', C) ok); the parameter types R' of me in C need to be 

adapted to C for R to be obtained {R = R'[C ~ — 4- C"]); the argument types Re need to 
all be subtypes of (or equal to) their same-indexed R type (C h Re<'.R)\ and, the return 

type R' of me in C needs to be adapted for R to be obtained {R = R'[C ~ — 4 C’\). 


Abbreviation 

Stands For 

F; C h e : i?e 

F; C h ei : i?ei , . . . , F; C h e„ : 

Ch ssfp{S,X\ C') ok 

c h ssfp{Si,x[,c) ok, . . . , c h ssfpiSr^, a;, C') ok 

Ch Re<:R 

C h i?ei < ■ Rl , . . . , C h < : Rn 

R'[C C'] 

{{R'[C C']) ■■■[C C']) 

R - W[C C'] 

Rl - R[[C C'], ...,Rn- K[C C'] 

Z = fsel{v) 

Zi = fsel{vi), ...,Zn= fsel{vn) 

as-fam{Z) \- v : A' 

as-fam{Zi) h : A(, . . . , as-fam{Zn) F Vn ■ A'^ 

as-fam{Z) h A! <\ A 

as-fam{Zi) h A( < : Ai , . . . , as-fam(Zn) F A'^ < : A„ 


Figure 3: Abbreviations Used in Figure 2 


Name 

Stands For 

fps 

family parameters 

ssfp 

substitution of family parameter selection for family parameter 

mtype 

method type 

fpub 

family parameter upper bound 

sat-by 

satisfied by 

non-conf 

non- conflicting 

fsel 

family selection 

as-fam 

as a family 


Figure 4: Helper Functions in Figure 2 


The rule (WF-Family) states that for a family $ to be well-formed: The components 
7 that are directly or indirectly requested by the components combined to obtain $ - i.e., 
fpub*{^) - must all (either themselves or an equivalent of theirs) exist in d* {sat-by{j, $)); 
and, that there must be no conflict between the 7 (namely, non-conf{j)). 

15 


Finally, the rule (T-Test) reads as follows: For a test to take the type A, the families 
defined in it, as well as its client instance I should be well-defined; the values v passed 
to the client method need to be of same family selections as those used for the client 
instantiation {Z = Z'); and, the types A' of the values need to be subtypes of (or of the 
same type as) the types A that the method called on / accepts {as-fam{Z) h A' <: A). 

Armed with the above three rules, below we sketch how y'hC'o addresses the promised 
ECP concerns. For more details, see Appendix A for the precise definitions of the clauses 
used in the premises of Figure 2. 

ECl. As exemplified by ENAS, this concern is addressed using calls to methods of other 
clients. The rule for such a call is (T-INVK3) in Figure 2. In that rule, the only 
clients involved are the caller client and the callee one. No assumption is made 
about any (dependent development of any) other client. 

EC2. As explained in Section 4.1, a program is a test along with the components 
and clients used. The typing rule of a test is (T-Test) in Figure 2. In that rule, the 
only components and clients that are involved in the decision making are the ones 
already used in I. That is C itself and the components used in Z. In other words, 
addition of new components or clients is of no influence on the rule. Likewise is 
the addition of new (well-formed) families. Note that, in the typing and subtyping 
judgements of (T-Test) - i.e., clauses in the bottom line of its premises - each 
judgement takes place inside its own family, exclusively. 

EC4. The respective rule of this concern is (WF-Family), with the key role player 
being sat-by{^,^). This clause pronounces $ sound so long as it does provide all 
the requested components (or equivalents of theirs). 

EC5. Again, the respective rule here is (WF-Family). Albeit, the role of non-conf{j) 
is more important for this concern. This clause makes sure that there is no conflict 
between the components combined to produce a family. 

EC6. The fact that a family is distinguishable from other families is clear. After all, 
a family is distinguished by its name. Moreover, the same clients are equally 
available to families with the same component combinations. That can be realised 
by observing it that every clause in (T-Test) - except ok that is irrelevant 
here - works equivalently for differently named families with the same combination. 

EC7. The respective rule of this concern is (T-INVK3). It is the C h ssfp{S,X' ,C) ok 
clause in the premises of that rule that is the most important here. The explicit 
correspondence between S and X' is the evidence submitted (by the programmer) 
for (7 to be a structural subtype of C’ . As such, the reuse of the method me of C 
by C is authorised by that clause. For every family parameter X[ of C , the above 
clause checks whether the substitution of the selection Si of C is valid for X[ of C . 

ECS. The respective rule and key clause of this concern are the same as those of 
the previous concern. In order to explain how this concern is addressed, how- 
ever, we need to zoom into C h ssfp{S,X' ,C) ok. Generally, a clause C h 
ssfp{X as © 7 , A, C") ok uses a premise valid- as{C,X,(Bq) that ensures the fol- 
lowing: Projection of a family parameter A of C to ©7 is valid. As such, it will 
reject the reuse of the method me of C otherwise. 
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5. Expression Families Problem 

In his seminal work on EFP [22], Oliveira provides two self-contained examples that 
obviate the necessity of solving EFP and the strength of MVCs: Equality Tests and 
Narrowing. We claimed in the Introduction that ECP is a variation of EFP. (See Section 3 
for the comparison on dealing with aggregate subtyping.) The first goal of this section is 
to substantiate that claim by offering solutions to Equality Tests and Narrowing in 

Sections 5.1 and 5.2, respectively. The second goal of this section is to get the reader to 
observe how straightforward of a solution to EFP a solution to ECP is. (See Remark 8 
for more.) In addition, as stated in Remark 2, the solutions in this section are based on 
integration of a decentralised pattern matching. Our third goal in this section is to offer 
a devoted presentation of that technique. 

5.1. Equality 

The purpose of the Equality Test exercise is to provide a statically safe solution for 
multiple dispatching that is also extensible. Like that of Oliveira, we offer a solution that 
simulates multi-methods [41, 42]. The driving example is structural equality between 
expressions. The test on Num, Add, and Sub is performed as follows: 


equal{Num(n), Num{n')) = 
equal{Add{ei, €2), Add{e[, 62)) = 
equal{Sub{ei, 62), Sub{e'i, 62)) = 
equal S) = 


(n == n') 

(1) 

equal[e\, e)) A equal{e2, e' 2 ) 

(2) 

equal[e\, e)) A equal{e2, e' 2 ) 

(3) 

±. 

(4) 


Such a formula is typically implemented as a pattern matching on the two expressions 
together. Using a familiar pattern matching, the implementation will, however, lose 
extensibility. To prevent that loss, our solution is first to decentralise the pattern 
matching by implementing each case using a single client. Then, one integrates as 
many of such clients as appropriate in another client, which also ties the recursive knot. 
EqNum and EqAdd below are the equality clients that correspond to Equations (1) 
and (2), respectively: 

01 client EqNum<X <l Num> { 

02 bool eq{X. Num Xi, X. Num X2,^oo\ e(X, X)){return X\.n == X2.n\} 

03 } 

04 client EqAdd<X <l Add> { 

05 bool eq{X. Add xi, X. Add X2, bool e{X,X)) { 

06 return e{x\. left, X2. left) && e{x\. right, X2. right); 

07 } 

08 } 

Note that both EqNum and EqAdd only take care of their own part of decentralisation. 
In a similar manner, one implements EqSub<X <l Sub 0 Num> and EqDef<X <l e> for 
Equations (3) and (4). Due to minimal shape exposure of X, none of the above four 
equality clients sees more than its pertinent part of the recipe. Nevertheless, for usage 
at the appropriate point (e.g., line 6 above), provisional access to the complete recipe is 
granted to them via their parameter e. The complete recipe itself can only be obtained 
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upon tying the recursive knot. In the terminology of Remark 2, that is referred to as the 
integration. Eq^ below integrates the appropriate clients for $i, i.e., EqNum and EqAdd: 

01 client Eqi<X <\ Num® Add>{ 

02 bool equal{X xi,X X 2 ) { 

03 return (a;i,a; 2 ) rnatch { 

04 case [X .Num, X .Num) ^ EqNum<X as Num>.eq{xi, X 2 , equal); 

05 case {X. Add, X. Add) => EqAdd<X as Add>.eq{xi,X 2 , equal); 

06 case _ ^ EqDef<X as e>.eq{xi,X 2 , equal); 

07 } 

08 } 

09 } 

Likewise, one implements Eq^^ to integrate the appropriate clients for $ 4 , i.e., EqNum, 
EqAdd, and EqSub. Armed with all that, then, one can perform the following tests: 

01 val tpfivei = . . . j jZ + 5 for $1 

02 val tpfour-^ = . . . //3 + 4 for <I>i 

03 Eqi<^i>.equal{tpfivei,tpfouri) //Returns _L. 

04 Eq^<^ 4 >.equal{tpf^,tpfmo^) //Returns _L. 

Observe how the technique caters for extensibility by leaving open the possibility of 
mixing-in new equality clients without the need to touch the existing equality cases. Note 
that, in this very case, the structural exercise happened to come with a default case. As 
noticed first by Zenger and Odersky [36] and several others afterwards, a default is not 
necessarily available. Section 5.2 contains an example where our solution works in the 
absence of default cases. 

5.2. Conversion and Narrowing 

Following Oliveira [22] , we say an expression is narrowed when all its ADT cases of a 
given group are cancelled into other case combinations that are deemed to be equivalent. 
It is common in the PL design community to provide extensions to a core PL such that 
the extension programs would then be narrowed to the core (for evaluation and the like). 
For example, GpH [43] and Utrecht Haskell [44] are both developed like that. Oliveira 
shows how his MVCs can be leveraged in favour of correctness for narrowing as a static 
guarantee that the result of this process will not contain instances from the unwanted 
ADT cases; it will instead contain other case combinations that are deemed equivalent. 

In this section, we generalise the narrowing exercise to conversion from one ADT to 
another. In particular, we will craft a conversion [[.] from an ADT with subtraction to 
an ADT with addition and negation (of signed integers): ][ei — 62 ! = |ei] + (—([[ 62 ]])). 
To that end, we first add a new component for negation. 

01 component Neg<X <l Num® Neg> { 

02 X inner ; 

03 NegiyX inner) {t\\\s. inner = inner;} 

04 } 

Then, we implement the decentralised pattern matching clients: N2N<Xi <l Num, 
X 2 <1 Num> to convert Num to Num, G2G<Xi <l Num 0 Neg, X 2 <1 Num 0 Neg> to 
convert Neg to Neg, and A2A<Xi <l Add, X 2 <\ Add> to convert Add to Add. The only 
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non-identical conversion is that of subtraction expressions to the equivalent combination 
of addition and negation: 

01 client S2AN<Xi <l Num(B Sub, X 2 <1 Num(B Add(B Neg> { 

02 X 2 convert{Xi.Sub x\, X 2 c(Xi)) { 

03 return new Add<X 2 >{c{xi.left),nevj Neg<X 2 >{c{x\. right)))-, 

04 } 

05 } 

In the snippet above, X\ and X 2 are the family parameters corresponding to the first 
and the second ADT, respectively. Furthermore, the parameter c of convert in line 02 is 
the function that devises the complete conversion recipe. The integration is not largely 
different from the ones seen thus far: 

01 client ConvSub<Xi <l Num(B Add(B Sub(B Neg,X 2 <1 Num(B Add® Neg> { 

02 X 2 doit{Xi xi) { 

03 return x\ match { 

04 case Xi.Num ^ N2N<Xi as Num, X 2 as Num>.convert{xi,doit); 

05 case Xi.Neg^ G2G<X\ as Num® Neg, 

^ X 2 as Num® Neg>.convert{xi, doit) ; 

06 case Xi.Add^ A2A<Xi as Add, X 2 as Add>.convert{xi,doit)\ 

07 case Xi.Sub ^ S2AN<Xi as Num® Sub, 

^ X 2 as Num © Add © Neg>.convert{x\ , doit) ; 

08 } 

09 } 

10 } 

Narrowing would, then, be a simple application of the above conversion from an ADT 
to the appropriate projection of the same ADT: 

01 client NarrowSub<X <] Num® Add® Sub® Neg> { 

02 A doit{X x) { 

03 return GonvSub<X, X as Num® Add® Neg>. doit (x) 

04 } 

05 } 

Supposing the availability of the two families below 

01 family = Num © Add © Sub © Neg; 

02 family $7 = Num® Add® Neg; 

finally, one can perform the following tests: 
val tpfmoneQ = . . . //(3 + 5) — 1 for 

GonvSub<^Q, .doit{tpfmone^) / /Returns (3 + 5) + (—(1)) for 4 ) 7 . 
NarrowSub<^e>.doit{tpfmoneQ) //Returns (3 + 5) + (—(1)) for 4>g. 

Remark 6 . As it turns out, using the same technique, one can come up with a widening 
function which acts in the opposite direction of narrow. The interesting consequence is 
that, combining widen and narrow gives rise to a manual simulation for the bidirectional 
adaptation of J&g [14]. 


Remark 7. Armed with the full arsenal of language features available in Scala, our 
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implementation also had the pleasure of using multiple inheritance. Hence, as shown 
by Haeri [26, §9.2], one also gets to a sequential composition [20, §17.3] variation of 
integration of a decentralised pattern matching. Interestingly enough, the latter variation 
mixes CBSE with Feature-Oriented Programming [45]. More precisely, it constitutes a 
verified software product-line [46, 47]. 

Remark 8. The straightforwardness in addressing EFP is gained by the peculiar com- 
bination of the concerns that ECP articulates. Below is more elaboration on the most 
remarkable points. In fact, EFP does already express its concern for a dialect of com- 
position completeness (i.e., EC4). ECP, on the other hand, adds EC5 on top of that 
for sound ab initio composition and ECS for sound extension of a composition. Our 
impression is that, only in the presence of both the completeness and soundness the 
integration of functions (on ADTs) is a matter of such a simple (yet strongly type-safe) 
relay. Without systematic handling of soundness, the programmer is on their own to 
manually relieve relevant anxieties of the compiler. The resulting circumvention will, 
unfortunately, intervene the program logic in ways that risk readability and correctness 
of implementation. The reader is invited to compare our online Scala implementation of 
the two EFP exercises with their MVC counterparts [22]. Our understanding is that the 
former implementation is much more readable and easier for a human-being to verify the 
correctness of. On the other hand, the scalability concern of ECP - i.e., ECS - entails the 
ease of decentralisation. By coincidence, ECS, EC5, and ECS are the only ECP concerns 
that MVCs do not score. 

6. Implementation 

Whilst 7 $Co still has no dedicated implementation (say a stand-alone compiler and 
an IDE), an embedding of its is indeed possible in Scala. Details of how to set up a 
complete Scala codebase for this purpose can be found in our earlier works: [48] and [26, 
§7 and §8]. In this section, we only explain what Scala code corresponds to what 7 $Co 
element of Section 2. We also study different aspects of each correspondence. 

The presentations in this paper are all in Scala. However, the same solutions can 
be used in any host PL providing multiple inheritance and type constraints.^ We use 
multiple inheritance for our cases to state their syntactic categories in addition to the 
ADT they are a case of. Type constraints are used as our means for checking soundness 
of component combinations. The Scala materials that we use here are those initially 
presented by Odersky and Zenger [49]. Our implementation, however, is rather inspired 
by Lightweight Modular Staging [39]. From another point of view, the implementation 
can also be regarded as a simulation of Polymorphic Variants [38] in Scala. 

We now start by the correspondent of a 7 $Co component, which is an ordinary Scala 
class with specially-wired type parameterisation. Consider the class Sub below for the 
Sub component of Section 2: 

class Sub [ 

E <: IAE[E], N <: Num[E, N] with E, S <: Sub[E, N, S] with E 
] (left: E, right: E) 


^We avoid Scala-specific terminology to make our work more broadly accessible. 
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Recall that the family parameterisation of Sub was X <l Num 0 Sub. The translation 
of that is what comes in line 2 above. In their order of appearance: E represents X, 
N represents X.Num, and S represents X.Sub. In Scala, the uses of < : in line 2 above 
demand nominal subtyping. (More on lAE later.) Part of the verbosity in the type 
annotations in line 2 above is because of the idiosyncrasies of JVM that dictate similar 
F-Boundings [50] to the Scala type system in return of correctness.® 

trait Phi4 extends IAE[Phi4] 

case class Num4(n: Int) extends Num[Phi4, Num4] (n) with Phi4 
case class Add4(left: Phi4, right: Phi4) extends 
Add[Phi4, Add4 ] (left, right) with Phi4 
case class Sub4(left: Phi4, right: Phi4) extends 
Sub[Phi4, Num4 , Sub4] (left, right) with Phi4 

The Scala counterpart of the $4 definition is even more verbose. The trait Phi 4 in 
line 1 above is like the “family $ 4 ” part of the family definition. lAE is our interface for 
integer arithmetic expressions. An ADT that is to use the arithmetic expression cases 
needs to tie the F-Bound knot of lAE in a similar fashion. Line 2, lines 3 and 4, and 
lines 5 and 6 above add the Num, Add, and Sub cases to Phi 4, respectively. Notice how, 
unlike 74 >Cq in which $4 simply bundles its appropriate components together, in Scala, 
one cannot reuse the exact same component names for the cases of Phi 4. For instance, 
the code above calls the Add case Add4 (as opposed to just Add). 

class ENAS [ 

E < : lAE [E] , 

N <: Num[E, N] with E, 

A <: Add[E, A] with E, 

S <: Sub[E, N, S] with E 
] { 

def eval(x: E, e: E => Int) : Int = x match { 

case _: Add[_, _] => new ENA[E, N, A] .eval(x, e) 

case _: Sub [_, _, _] => new ENS [E, N, S] .eval(x, e) 

case _: Num[_, _] => new EN[E, N] ,eval(x, e) 

} 

} 

The code above is the Scala counterpart for ENAS of Section 2. For the first differ- 
ence, note the at the beginning of each pattern. In Scala, in addition to their types, 
patterns need names as well. 

object test2 { 

val three_plus_f ive4 = Add4 (Num4 (3) , Num4 (5) ) 

def runi = new Eval4[Phi4, Num4, Add4, Sub4] . do_it (three_plus_f ive4 ) 

} 

Finally, three_plus_f ive4 above constructs a corresponding expression for 3 0 5 
in 4 ) 4 . Note the interesting advantage gained by the tight binding of Add4 to Phi4: 
Unlike tpf that requires explicit mention of $4 upon every component instantiation. 


®Alike F-Bound treatments are, in fact, popular for solving similar problems in earlier research. 
Consider Torgersen[8] for EP, Kamina and Tamai [11] for lightweight family polymorphism, and Bruce 
et al. [51] and Madsen and Ernst [28] for virtual classes. 
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explicit mention of Phi 4 is absent in Add4 and Num4 uses in line 2 above. On the 
contrary, because Phi 4 has no knowledge about its cases, in line 3 above, one needs to 
redundantly list the cases of Phi 4 upon instantiation of Eva 14 for it. Contrast that to 
version where the sole mention of d >4 is enough. 

Remark 9. Our definition of syntactic compatibility is rather extensional in that it 
works for both structural and nominal subtyping. Here we present our implementation for 
nominal subtyping. However, the same techniques are applicable for structural subtyping 
too - especially, in a host PL like Scala with support for both sorts of subtyping [52]. 

7. Conclusion and Future Work 

In this paper, we introduce ECP by precisely formulating its eight concerns (Sec- 
tion 1). We show the benefits of solving ECP along with a technology used to solve it 
(Section 2). We present the syntax (Section 4.1), static semantics (Appendix A), and 
dynamic semantics (Appendix B) of 7 $Co as a formal solution to ECP. We detail the 
selected parts of the yd’C'o semantics that play key roles in solving ECP (Section 4.2). 
Furthermore, we show how y'hC'o can easily be used for a solution to EFP (Section 5). 
Finally, we explain how to simulate yd’C'o in Scala (Section 6). 

The immediate future work to this paper is proving the standard theoretical results 
(e.g., subject reduction, progress, and type soundness) about As stated in the 

introduction, ECP is a variation to EP. As such, is the first PL with a formal 

semantics that is designed for solving EP. It is especially tempting to try formal proofs 
for that claim. An extended future work would, then, be flourishing Section 4.2 to 
formal proofs for y'hC'o solving ECP. A fresh look into the paper reveals that it also 
introduces a new variation on family polymorphism that we would call component family 
polymorphism. Implementing 7 d>Co is the other obvious future work of this paper. That 
would, on its own, form an interesting test bed for component family polymorphism. 
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Appendix A. The Static Semantics of 7 ^Cq 

This section aims at providing typing rules for as done in Appendix A. 6. 

The major tool to that end are well-formedness (Appendix A. 4). The other subsections 
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provide other utilities for that purpose: Appendix A.l presents the lookup functions; 
Appendix A . 2 discusses the subtyping rules; and, Appendix A . 3 and Appendix A . 5 
offer other utilities for well-formedness and typing respectively. 

Given the list comprehension notation that we borrow from the Lightweight Family 
Polymorphism literature (Section 3 ), the rules of our static and dynamic semantics are 
likely to take time to absorb. Here are a few rules of thumb that will accelerate the 
reader: Whenever, in a phrase, a list of items is used in a place where a single item 
of the type is expected, the comprehension is abbreviating a list of phrases rather than 
a single one. For example, the phrase G h i? ok denotes the following list of judge- 
ments G F i?i ok, . . . , G h Rn ok, for the appropriate n. When, in a phrase, there 
are two comprehensions in two places where a single item is expected, a list of phrases 
is meant, where the two lists are iterated together. For instance, ^<Z>jX.j denotes 
7 i<Z>/A.7i, . . . , 7„<Z>/X.7„. Note that, in every substitution, the 7 on the left-hand- 
side is of the same-index that the right-hand-side one is of. As stated earlier on too, in 
our semantics, we refer to that property as the same-indexed convention. 

We maintain a similar convention for iteration of three lists together for when three 
single items are expected in a phrase. For example, as-fam{Z) h u : A' abbreviates 
as-fam(Zi) h v\ : A^, . . . , as-/am(Z„) h Vn '■ A(j, where Z, v, and A' are iterated together 
to obtain the individual judgements. On the contrary, when, in a phrase, there are 
four comprehensions in places where four single items are expected, there is a nesting 
of iteration loops, in each loop a pair of comprehensions are to be iterated together. 
For example, for 7<Z>/A.7] /, the pair R and / are iterated together, and the 

pair 7<Z> and A. 7 are iterated together (inside the first iteration). Throughout the 
appendices, whenever such unfolding actions are needed, we explain the instances. 

Appendix A.l. Lookup Functions 

Before we move to the lookup functions themselves, we explain some auxiliaries func- 
tions that will become handy over the lookup. Dehne ‘the component mix of a selection' 
cmm($) = (<h,©7) when $ = ©7 and cmixs{^ as © 7) = ($,©7). As another aux- 
iliary, define fps{G<Xi <\ . . . , A2 <1 A„ <l . . . >) = Ai, A2, . . . , A„. On top of 

those two, define pfcmix{G<Z>, Xi) = cmixs(Zi) when either A^ G fps{G). In words, 
pfcmix{I,X) is ‘the passed family and components mixture for parameter A to get I.’ 
Finally, define ‘the family parameter upper bound' fpub{G< . . . , A as ©7, . . . >, A) = ©7. 


fields {X. j) = fields (j) (F-VCase) fields {X) = e (F-FPar) 

component 7< • • • > <| • • • {i?/; • • • } 

^ (F-Comp) 

fields{-i) = Rf 

fields{'-f<X as (B fi>) = fields {j) (F-FProj) 

cmixs(Z) = (d>,©7) 7 G ©7 fields{j) = Rf 

= = (F-Case) 

fields {'j<Z>) = R[Z/X,j<Z> / X.^] f 


Figure A. 5: Field Lookup of 'J^Cq 
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Figures A . 5 and A. 6 are routine lookup functions for the fields and method types. We 
start the explanation by the former. The rule (F-VCase) is an immediate implication 
of Remark 10. Recall that A.y = 7 . A family parameter has no fields, hence, (F-FPar). 
The rule (F-Comp) states that the fields of a component are those mentioned in its own 
body. (Note that we maintain a convention on the field names being distinct.) 

It is, finally, when a family (or a projection of it) is used for component instantiation 
that relative types are replaced by absolute ones. (F-Case) formulates the process for 
fields. In the last rule, the abbreviation is doubly-folded: For a fixed X and a fixed Z, the 
phrase ^<Z> jX:^ stands for 7i<Z>/X.7i, . . . ,7„<Z>/A.7„. Atop, R[- ■ ■ ] / abbreviates 
i?i [• • • ] /i, . . . , i?„[- • • ] /„. (Namely, inside the pair of square bracket lies one folding; 
there is another folding outside the pair.) Note that the replacement process is order- 
sensitive. That is, for every appropriate i, the relative is replaced by the same- 
indexed component instance 7^<$>. Likewise, for every appropriate j, the relative type 
Rj is that of the field fj . 


Rm{Rx){---} e M 
mtype{m, G) = R ^ R 


(MT-G) 


/ = G< ■ ■ ■> fps{C) = X mtype{mc, C) = R ^ R 
fpub{G,X) = 07^ pfcmix{I, X) = ($,07) 
mtype{mc,I) = (!?—>■ i?)[d>/A, 7<d>>/X.7'] 


(MT-Inst) 


Figure A. 6: Method Type Lookup of 7$Co 


The method type of m in G, as stated by (MT-G), is trivially calculated using its 
nominated argument and return types. In (MT-Inst), the method type of m in an 
instance of a client C is that of G itself, updated with the instantiation information. 
The notation 7<$>/A.y is again doubly-folded and deserves dedicated unfolding ad- 
vice. 7<$>/A.7' stands for 7<$i>/Ai.7', . . . , 7<$„>/A„.7'. Besides, for a fixed X and 
a fixed $, 7<$>/A.7' stands for 7i<$>/A.7(, . . . , 7fc<d)>/A.7(,. That is, the same- 
indexed convention is maintained in both foldings here. We maintain the same-indexed 
convention throughout 7<I>Go. In particular, component combinations are considered in 
their exact same order that they are listed by the programmer. The 7 $Gq semantics 
does not put effort into trying other (equally meaningful) permutations. 

Appendix A. 2 . Subtyping 

The subtyping rules of 7 $Gq are presented in Figure A. 7. In line with Figure 1, the 
rules are divided into those pertaining to prior family introduction (Relative Subtyping) 
and after that (Absolute Subtyping). In the former group, the decision is made with 
respect to the relative enclosing definition (G), whereas, for the latter, a family ($) is 
the basis of decision. The reflexiveness and transitivity rules are standard. The other 
two are specifically relevant to ECP. They are along the lines that the cases of an ADT 
are all different forms of it. Note that these last two rules are likely not to be correct for 
CBSE applied in other disciplines. In fact, whilst other disciplines are entitled to add 
their own rules here, it is only the reflexiveness and transitivity rules to expect from =. 
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Relative Subtyping G\~ R<-.R' 


G\- R<:R (S-ReflG) 

Ghi?<:R' GhiJ'cR" fpub{G,X)=®j 7607 

(S-TrANG) ;; (S-VCase) 


G h i? <: R" 


G h X.7 <: X 


Absolute Subtyping 


$ h A <: A' 


$hA<:A (S-ReflF) 


$ h A <: A' $ h A' <: A" 


$ h AcA" 


(S-TranF) 


$ = 


7 e 


$ h 7<$> < : $ 


(S-Gase) 


Figure A. 7: The Two Sorts of Subtyping in 7 <I>Co 


Remark 10. As announced in Section 4 A, ^^Gq assumes the availability of an equiv- 
alence relation =. Replacement of a component by an equivalent should go unobserved 
by the recipient code. The two aspects of this unobservedness are: constructibility with 
the same syntax and provision of the same interface. Note that, in 7<i)Go, the latter 
condition also means that they must come with the same fields and similar ‘requires’ 
interfaces. The presence of those aspects makes the equivalent component substitution 
in ok-at{.) safe (Figure A. 9 ). Note that, whilst we require equivalent components to share 
the observed interface, their implementation of the requested services - as well as the 
rest of their interfaces - can well differ.® Unlike the case rules of Figure A. 7 , we find the 
necessity of = to be a property of CBSE in general (rather than ECP exclusively). 

Many real-world PLs do already have means that can be leveraged to guarantee the 
above unobservedness. Examples are the ordinary C+0 template mechanism, C+0 
concepts or Haskell type classes, and the implicits of Scala. The study of advantages 
and disadvantages of each means is a topic for future research. 

Appendix A. 3. Other Well-Formedness Utilities 


fpub{G, X) = ©7 {7p} C {7} 


valid-as{G , X, ©7p) 

4 * = ©7 {>} C {7} 

valid-as{^, (BXp) 


(Valid-As-G) 


(Valid- As-F) 


Figure A. 8: Valid Projection of Component Combinations in 7^Co 


We stated in Section 4.2 that valid-as{.) is at the heart of 7$Go’s support for ECS. 
Figure A. 8 details that function. valid-as{.) answers the question of whether the compo- 
nent combination passed as its second argument is a valid projection of its first argument. 


®This is similar to the substitutability of Liskov [53], except that her work was exclusive to inheritance. 
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The essence of valid-as{.) is the simple subset check {^} C {7} where 07 is the available 
component combination and is the requested projection. The rule (Valid- As-G) 
conducts the validity check for components and clients, whilst ( Valid- As-F) does that 
for families. We now continue to a series of other auxiliaries. 

Define fpub*{.) as the transitive closure of fpub{.): 

fpub*{'Y) = fpub{'Y)U y fpub*{j’). 

Yefpub{j) 

Define also the set of unwanted components for a component 7 as Mcomps(component 7 <... 
yj 7>) = 7. Next, define ‘the passed family selection to an instance’ psfi{C<Z>, Xi) = Zi 
when Xi £ fps{C). On top of the definitions of this section, we define more complicated 
utilities in Figure A. 9 . In words, the rule (NC-Comp) manifests it that so long as the 
transitive closure of the components in the ‘requires’ interface of a given set of compo- 
nents 7 has no intersection with the components that are unwanted by 7, they are in no 
conflict. Using that rule, then, the rule (NC-Cli) explains that a client has no conflict 
at its family parameter X when the upper bound of X is non-conflicting. 

The rules (OA-CFInst) and (OA-CPInst) are both on legislation of substituting 
family selections for family parameters of a client. They consider the cases where a full 
family or a projection of it is used for that purpose, respectively. The essence of the two 
is their last two premises: ^7 = and 7 = 7'. The first condition checks whether 
the passed combination does indeed have the same length of the requested combination. 
Then, the second checks whether every passed component is in = relationship with its 
same- indexed requested one. 


fpub*(Y) n y ucomps^j) = 0 


'rGfpub-iY 

non-confiff) 

fpub{C\ X) = ©7 non-conf{j) 
non-conf{C, X) 


(NC-Comp) 


(NC-Cli) 


I = C< -> psfi{I,X) = ^ 

fpub{C,X) = ®Y' #7 = #f 

ok-at{I, X) 


$ = ©7 

(OA-CFInst) 


/ = C< • • • > psfi{I, V) = $ as 7 
fpub{C,X)=(BY' #7 = #f 
ok-at{I, X) 


valid-as{^, 7) 

- ±-r 

7 = 7 


(OA-CPInst) 


Figure A. 9: non-conf{.) and ok-at(.) 


^^The “p” subscript in 7 p is for projection. 
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Appendix A. 4- Well-Formedness 

In correspondence with Figure 1, Figures A. 10 and A. 11 divide the well-formedness 
rules into two parts: relative and absolute, respectively. When a relative entity r is well- 
formed in G, we write “G h r ok” . Likewise, when an absolute entity a is well-formed, 
we write “a ok” . The rest of this section provides informal explanation for both. 


X : i?, this : X.^;j \~ : R' 

'y \- R' <:R 'y \- R, R' , R ok 

7 h i? m-f{R S){return e-y-,} ok 


(WF-MComp) 


x:R]Ckec-R! CkR!<-.R G h i?, i?', i? ok 
G h i? mc{R T){return ec; } ok 
fieldsi'y) = RJ 

— = — = (WF-Ctor) 

7(i? /){this./ = /;} ok 

non-conf(yy) AT ok 7 h My ok 7 h i? ok 
component ^{R /; K My} ok 
Xi = fps{C) non-conJ{C,X) C h Mq ok 


(WF-MCli) 


Gheok 


client C{Mc} ok 
(WF-Empty) 


(WF-Comp) 

(WF-Cli) 


X e fps{G) 


Gk X ok 


(WF-FPar) 


fpub{G, X) = (B^ 7 e ©7 

G h X.j ok 


(WF-VCase) 


Figure A. 10: Relative Well-Formedness in 

The rules (WF-MComp) and (WF-MCli) are routine. They pertain to the well- 
formedness of component and client methods, respectively. Note that G h i? ok ab- 
breviates G h i?i ok, ...,G h Rn ok. (WF-Ctor) is about (component) constructors 
and is routine. (WF-Comp) states that a component is well-formed when there is no 
conflict between its (transitively) requested and unwanted components and the following 
are all well-formed: its constructor, its methods, and field types. Given that a client 
has no constructor or fields, (WF-Cli) is similar but only checks the well-formedness of 
(client) methods. The other difference is that (WF-Cli) requires the absence of conflict 
separately for each (and every) of its family parameters. Note that non-conf{G, X) ab- 
breviates non-conf{G, Xi), . . . , non-conf{C, X„). According to (WF-Empty), the empty 
list is always well-formed w.r.t. a relative definition. (WF-FPar) states that the family 
variables of a relative definition are all well-defined w.r.t. to it. Finally, due to (WF- 
VCase), X."f — i.e., the component 7 of the family parameter X - is only well-formed 
when the enclosing relative definition G has already enforced the availability of 7 in the 
family to substitute for X to instantiate G. 

The rule (WF-Family) is already explained in Section 4.2. It only remains to present 
two formal definitions. Write sat-by{^,^) when G $. 7 = 7'. We also overload the 
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j=fpub*(^) sat-by(^^^) non-conf(j) 
family $ = • • • ok 
I = C< • • • > C ok X = fps{C) ok-at{I, X) 
I ok 


(WF-Family) 
(WF-Inst) 


Figure A.ll: Well-Formedness of Absolutes in 7 ^Cq 


fpub*{.) function for families: fpub*{^) = |J fpub*{’j). The rule (WF-Inst) mentions 

the conditions for the well-formedness of an instance. First, the instantiated client it- 
self needs to be well-formed. Second, the family selections sent as arguments to each 
(and every) family parameter should be acceptable. Note that ok-at{I,X) abbreviates 
ok-at{I, Xi), . . . , ok-at{I, X„). 

Appendix A. 5. Typing Utilities 

In this section, we define a handful of auxiliary functions that we use in the typing 
rules of y'hC'o (Appendix A. 6). We start by the function fp{S) for the family parameter 
of a selection S. Define fp{X) = X and fp{X as © 7) = X. Furthermore, define the 
^component combination used in a selection for a client’ - denoted by cls-ccomb{.) - as 
follows: 

f cls-ccomb{C,X as © 7) = ©7 when X G fps{C) 

\cls-ccomb\c ^ X) = ©7 when fpub{C, X) = ©7 

The last simple function that we define here is projs{C, X) for the list of projections of 
X in the body of C. (We do not present a more precise definition for projs{., .).) 

The above few functions pave the road for more complicated ones that will be of 
direct use in the next section. Consider Figure A. 13. A predicate C h ssfp{S, X' ,C) ok 
claims that ‘substitution of the family parameter selection S for the family parameter 
X' of C is acceptable. The rules (S-WFP) and (S-PFP) list the conditions that justify 
such a predicate. They correspond to the situations when S' is a family parameter X 
itself and when a projection of it is used. 

Last comes the rule (FC), which enumerates the conditions in which the notation 
[5" /A"^] 

R\C — 4- C] is defined in addition to what it represents. That notation is for updating 

a relative type R acquired from a call to a C method for the use within a client C. When 
the roles of C and C are not of interest and we are rather after the update action itself, 
we use the shorter notation R[X' ^ S]. The last group of substitutions advised by 
the rule (FC) in its right-hand-side of the conclusion deserves further explanation: The 
(FC) rule aside, when {7'} C {7}, we generally use {X as © 7) as © 7' for X as © 7’. 

Appendix A. 6. Typing 

Figure A. 13 illustrates the typing rules for 7$Co expressions. The scheme of these 
rules is T; G h e : i?. Here, T is a type environment, which is a partial function from 
variable names to their types. The scheme reads ‘with the type environment F and inside 
G, the expression e is typed to R.' 
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The rules (T-Var) and (T-Field) are routine. The rule (T-InvKi) is less straight- 
forward in that it allows the arguments passed to a method to also be of subtypes of 
the respective nominated parameter types. (T-New) offers the same flexibility when 
sending arguments to a component 7’s constructor. In addition, it checks if 7 is basically 
well-formed in G. (T-INVK2) is like (T-InvKi) but simpler: After all, unlike an rrij, an 
me has no receiver expression. The rule (T-INVK3) is already explained in Section 4 . 2 . 

Figure A . 14 is on our single rule for typing a test r. (Recall the r syntax in Figure 1 .) 
Given that this rule was already explained in Section 4 . 2 , we drop further explanation 
here. It remains for us, nevertheless, to give formal definitions for the auxiliary functions 
used in it. The ^family selection of a value’ is defined as fsel{new j<Z>(e)) = Z and 
fsel{new 'y<Z>(v)) = Z if and only if fseliv) = Z. Moreover, define a ‘family selection 
considered as a stand-alone /aTTiiZy’ as follows: as-fam{^) = $ and as-fam{^ as ©7) = 
where the fresh family d*' is defined to be = ©7 when valid-as{^, ©7). 

Appendix B. The Dynamic Semantics of 7$Co 

Although we do not really make use of the 7$(7o dynamic semantics in this paper, this 
section presents the dynamic semantics for completeness purposes. The dynamic 

semantics is remarkably less complicated than its static semantics. Before we get into 
the dynamic semantics, we would like to draw the reader’s attention to the following 
comparison about Figure 1 : Although a client expression ec can take the form mc{ec), 
there is no corresponding form for an absolute expression Ca- That is indeed a design 
choice we made in the favour of simplicity of the dynamic semantics. More precisely, once 
the static semantics of a 7 $Cq program is checked, we assume any method call mc(ec) 
in a client C< • • • > to have been normalised to their equivalent C< ■ ■ ■ >.mc{ec) call. As 
such, calls of the mc{ec) form will no longer exist in a program to take a counterpart 
form in Ca- 

After such normalisations, similar to the familiar type instantiation, 7$Co offers a 
family parameter substitution phase. To get to the formal definition, we first present 
the function rtypes{.) for the relative types of a relative expression: 

rtypes{x) = e 

rtypes{er.f) = rtypes{er) 

rtypes{er .m^{Gr)) = rtypes{er),rtypes{ef^) 

rty pes {new X.j(G^)) = X.j,rtypes{eG) 
rtypes{C<S>.m{ec)) = fps{S), rtypes{ec) 

Next, define fps{ec) = {X \ X e rtypes{ec) V X._ G rtypes{ec)} for the family 
parameters that occur in an expression ec- 

We can now move to the function mbody{., .) in Figure B. 15 . The function mbody{m, G) 
returns the body of a method m of G along with the set of formal parameters that m takes 
and the definition site of m. We overload the mbody{., .) function to also handle the case 
when a G is to be instantiated using the family selections Z. The notation e[X 1— )■ Z] (read 
e with X bound to Z) is defined as e[X Z] = e{Z / X,^<Z> / X.'^' , Z as ©7"/A as ©7"] 
where: projs{G, A) = A as ©7" and ( 4 ) as © 7) as © 7' = $ as © 7' when {7'} C {7}. 

Finally, Figure B .16 defines the 7 $Gq operational semantics. The judgements there 
are of the scheme e — )■ e' (“expression e reduces to e' in one step”). There are three 
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fpub{C, X) = 07 fpub{C', X') =07' 7 = 7' 

Ch ssfp{X,X',C') ok 

valid-as{C, X, 07) fpub{C' , X') = 07^ 1 = l' 

C \- ssfp{X as 07, X',C') ok 

fpub{C' , X') = 07^ ds-ccomb{C, S) = 07 

fp{S) = X projs{C ,X') = X' as 07" 


R[C 


[S/X'[ 


(S-WFP) 

(S-PFP) 

(FC) 


> C'] = R[X/X',X.^/X'x',S as 07"/X' as 07"] 


Figure A. 12: Typing Utility Functions 


T;Ghe:i? 

F; G h X : F(x) (T-Var) 

F;7 h e-y : R fields (R) = R f 
(T-Field) 

F ;7 h Cy./j : R^ 

F; G h e : X.j mtype(rn^,j) = R ^ R 

F;Ghe:ir GhR'cR , 

— ^ (T-Invki) 

F; G h e.my(e) : R 

G h X.7 ok fields{X."f) = R 

r;Ghe: 7 F GhRcR , 

— ^ (T-New) 

F; G h new X.'j(e) : X.j 

mtype (me , G) = R ^ R T;G \~ e : R' C R' <:R 

(T-INVK 2 ) 

F;Gh mc(e) : R 

F; G fps(C) = IG =_#S 

G h ssfp(S, X', C) ok mtype(mc, G') = R' —>■ R' 

r = r^[C^^^G'] GhWeCR R = R'[G^^^G'] 

T~1 I / — \ T-» 


Figure A. 13: Expression Typing in -y^Co 


ok I ok mtype(mc,I) = A 
Z = fsel(v) I = G<X> ~Z = Y' 
as-fam(Z) \- v : A' as-fam(Z) \- A' <■. A 

; I.mc(v) : A 


(T-Test) 


Figure A. 14: The Test Typing of 7<I>Co 
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reduction rules in Figure B.16: one for field access, one for component method invocation, 
and one for client method invocation. Note that the reduction rules may be applied at 
any point in an expression. Hence, y'hC'o operational semantics also offers the obvious 
congruence rules. The rules in Figure B.16 are standard and we drop further explanation. 
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G{- ■ ■ M ■ ■ ■} R m{R a;){return e; } G M 
mbody{m, G) = (x, e) 


(MB-Rel) 


mbody(m, G) = (x, e) X = fps{G) 
fpub{G,X) = 07' cmixs{Z) = (-,©7) 
mbody{m,G<Z>) = {x,e[X 1— )■ Z]) 


(MB-Abs) 


Figure B.15: Body of Method m of G 


Computation 

fields{'j<Z>) = _ / 


new 'Y<Z>{e).fi — >■ e- 
mbody{m,j,^<Z>) = (x,e) 


(R-Field) 


new 7<Z>(e).m-y(e') = e[e'/ai, new 7<Z>(e)/this] 


— (R-InvKi) 


mbody(mc,G<Z>) = (x,e) 
C<Z>.mc{e) = e[e/x] 

Congruence 


(R-INVK3) 


e — >■ e 


e.f ^ e'.f 


- — (RC-Field) 


e.m(e) — >■ e'.m{e) 


(RC-Invki 


(RC-INVK2) 


e.m{. e.m {. . . ,e', . . .) 

^ e'i 

G<Z>.m {. . . , Ci, . . C<Z>.m {. . . , e', . . .) 

G e' 

new j<Z>(. . . ,6i,. . .) new 7 <Z>(. . . , e', . . .) 

Figure B.16: The Operational Semantics 


(RC-INVK3) 


(RC-New) 
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